home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1993 July / InfoMagic USENET CD-ROM July 1993.ISO / sources / unix / volume2 / window / part1 < prev    next >
Encoding:
Internet Message Format  |  1986-11-30  |  48.8 KB

  1. From: Tom Truscott <decvax!mcnc!rti-sel!trt>
  2. Subject: wm - a window manager (part 1 of 4)
  3. Newsgroups: mod.sources
  4. Approved: john@genrad.UUCP
  5.  
  6. Mod.sources:  Volume 2, Issue 31
  7. Submitted by: Tom Truscott <decvax!mcnc!rti-sel!trt>
  8.  
  9.  
  10. #! /bin/sh
  11. # This is a shell archive, meaning:
  12. # 1. Remove everything above the #! /bin/sh line.
  13. # 2. Save the resulting text in a file.
  14. # 3. Execute the file with /bin/sh (not csh) to create the files:
  15. #    README
  16. #    wm.1
  17. #    USINGWM
  18. #    Paper.jacob
  19. # This archive created: Fri Aug  2 13:13:13 1985
  20. export PATH; PATH=/bin:$PATH
  21. echo shar: extracting "'README'" '(1606 characters)'
  22. if test -f 'README'
  23. then
  24.     echo shar: will not over-write existing file "'README'"
  25. else
  26. sed 's/^X//' << \SHAR_EOF > 'README'
  27.     A Revised Edition of the `wm' window manager
  28.         Matt Lennon    (919) 541-6919
  29.         Tom Truscott    (919) 541-7005
  30.         Research Triangle Institute, NC
  31.         P.O. Box 12194
  32.         RTP, NC  27709
  33.  
  34.  
  35. To install WM:
  36.  
  37. 1) Install the provided version of the Curses library. This library
  38.    has bug fixes *necessary* to the proper operation of WM.
  39.    If you don't actually install libcurses.a in /usr/lib, you
  40.    must indicate this in the WM Makefile (the LIBCURSES macro),
  41.    and you must copy the provided curses.h to this directory
  42.    so that it will be included during compilation.
  43.  
  44. 2) Set the value of BIN in the WM makefile to the
  45.    directory where the WM program should reside.
  46.  
  47. 3) Type 'make install'.
  48.  
  49. 4) Install the WM manual page, wm.1, in the appropriate place.
  50.  
  51.  
  52. Note 1: This version of WM is horribly 4.2bsd-dependent, using pseudo-ttys,
  53.         the 'select()' system call, 4.2-specific ioctl's, etc.
  54.         Conceivably, it could be made to run under 4.1bsd with some
  55.         minor mods, but porting to other versions of UNIX would
  56.         probably entail a major rewrite.
  57.  
  58. Note 2: The paper 'USINGWM' is a brief essay on how we use WM
  59.     here at RTI, and should prove helpful in getting used to
  60.     the WM style of doing things.  It also describes some
  61.     problems/glitches with WM that you should be aware of.
  62.  
  63. Note 3: Included in this distribution is a paper (Paper.jacob)
  64.         by the original WM author that describe WM's
  65.         development and structure.  While the description of
  66.         the 4.2bsd version of WM pertains to an earlier version,
  67.         the basics are still the same, and this paper is good reading.
  68. SHAR_EOF
  69. if test 1606 -ne "`wc -c < 'README'`"
  70. then
  71.     echo shar: error transmitting "'README'" '(should have been 1606 characters)'
  72. fi
  73. fi # end of overwriting check
  74. echo shar: extracting "'wm.1'" '(5635 characters)'
  75. if test -f 'wm.1'
  76. then
  77.     echo shar: will not over-write existing file "'wm.1'"
  78. else
  79. sed 's/^X//' << \SHAR_EOF > 'wm.1'
  80. X.TH WM local wm
  81. X.SH NAME
  82. wm \- window manager
  83. X.SH SYNOPSIS
  84. X.B wm
  85. [ \fB\-n\fP ]  [ \fB\-f\fP rfile ]
  86. X.SH DESCRIPTION
  87. X.I Wm
  88. manages a collection of windows on a display terminal.
  89. X.PP
  90. It determines what type of terminal you are using from
  91. the environment parameter $TERM
  92. (see
  93. X.IR environ (5))
  94. and then uses
  95. X.IR curses (3)
  96. to adapt to it.
  97. X.PP
  98. Each window has its own UNIX shell
  99. (as specified by the environment parameter $SHELL;
  100. the default is
  101. X.IR sh (1)),
  102. running in parallel with those in the other windows.
  103. The idea behind this scheme is that you can use each window
  104. for a series of commands dealing with a single topic.
  105. Then, you can change back and forth between the windows without
  106. losing your place in any of them.
  107. X.PP
  108. At any time, you can give commands to change the window you are typing in,
  109. to move a window or change its size,
  110. or to create or kill a window.
  111. Windows can overlap or completely obscure one another.
  112. Obscured windows can subsequently be "lifted" up
  113. and placed on top of the other windows.
  114. When a window is partially or completely obscured,
  115. subsequent output to that window will be held until the window
  116. becomes completely visible again, effectively suspending the job
  117. running in the obscured window.
  118. X.PP
  119. When the program is started,
  120. it will attempt to restore the sizes and positions of the windows
  121. in use when you last ran
  122. X.IR wm
  123. (unless you use
  124. X.B \-n
  125. option).
  126. If you give the
  127. X.B \-f
  128. X.I rfile
  129. option,
  130. X.I wm
  131. tries to restore windows from the file
  132. X.I rfile.
  133. Otherwise, it first tries the file
  134. X.I .wmrc
  135. in the current directory,
  136. then, if necessary,
  137. X.I .wmrc
  138. in your home directory.
  139. XFailing all this,
  140. X.I wm
  141. will give you a window the size of your screen.
  142. Now, you can type UNIX commands in the new window.
  143. X.PP
  144. X.I Wm
  145. commands can be issued at any time.
  146. Every
  147. X.I wm
  148. command consists of a prefix character \fI<wm-esc>\fP followed by one
  149. more character, possibly followed by some arguments.
  150. Any other characters typed on the terminal are treated as input
  151. to the program in the current window.
  152. To enter \fI<wm-esc>\fP itself as input to a program, type it twice.
  153. The \fI<wm-esc>\fP is initially set to ASCII ESC, but there is
  154. a command for changing it.
  155. X.PP
  156. The available
  157. X.I wm
  158. commands are \fI<wm-esc>\fP followed by:
  159. X.IP \fBn\fP
  160. Create a new window.
  161. To do this, move the cursor to the position you want the
  162. lower left corner of your window
  163. to occupy,
  164. using the keys
  165. X.B k
  166. (up),
  167. X.B j
  168. (down),
  169. X.B h
  170. (left), and
  171. X.B l
  172. (right)
  173. and also
  174. X.BR K ,
  175. X.BR J ,
  176. X.BR H ,
  177. and
  178. X.B L
  179. (for large increments in the respective directions).
  180. Then type an
  181. X.BR x .
  182. Then move the cursor (using the same commands) to the upper
  183. right corner, and type another
  184. X.BR x .
  185. X.IP \fBi\fP
  186. Identify each window by outlining it with its window number
  187. (each window has a one digit name, e.g.
  188. #\fB1\fP, #\fB2\fP, #\fB3\fP,
  189. used in referring to that window).
  190. X.IP \fIdigit\fP
  191. Change the current window.
  192. The named window is placed on "top" of the screen
  193. (that is, in front of any other windows that had been obscuring it).
  194. Input from the keyboard will now be sent to this window.
  195. (Delayed responses to commands entered in other windows will,
  196. of course, continue to be routed to their correct windows.)
  197. X.IP \fBl\fP
  198. Change to the last-used window.
  199. Change back to the window that had most recently been the current window.
  200. X.IP \fBm\fP
  201. Move and/or change the size of the current window.
  202. X.I Wm
  203. asks for the lower left and upper right corners of desired
  204. new position of the window (same convention as for new windows).
  205. It is not advisable to move a window except when
  206. the program running in it is at the shell prompt level.
  207. In particular, screen-oriented programs such as
  208. X.I vi
  209. can get very confused if their window size is changed while they are running.
  210. X.IP \fBt\fP
  211. Reset the environment variables $TERM and $TERMCAP for the current window.
  212. This may be necessary if these variables get unset or scrambled,
  213. for instance during a remote login.
  214. This command should only be invoked when
  215. the program running in it is at the shell prompt level because
  216. it operates by sending commands to the shell as if
  217. they were typed in from the keyboard.
  218. X.IP \fBd\fP
  219. Dump current window contents. An image of the current window is
  220. written to the file
  221. X.I wmdump
  222. in the current directory.
  223. X.IP \fBk\fP
  224. Kill the named window.
  225. XSends the signal SIGHUP (hangup) to the processes associated with the window,
  226. then erases the window.
  227. (The
  228. X.I name
  229. of this window may later be re-used in creating a new window.)
  230. X.IP \fBp\fP
  231. Change the prefix character.
  232. X.IP \fBr\fP
  233. Redraw the screen.
  234. Clears the entire screen and redraws what should be there.
  235. Helpful after garbage (like a broadcast message) has arrived.
  236. X.IP \fBq\fP
  237. Quit.
  238. End the current 
  239. X.I wm
  240. session.
  241. XFirst terminates the processes associated with each
  242. X.I wm,
  243. window by sending them the signal SIGHUP (hangup).
  244. Then, if you have changed the window configuration during the session
  245. (and didn't specify the 'no restore' (\fB\-n\fP) option),
  246. asks you if you want to save the current window configuration
  247. for the next session.
  248. Then exits.
  249. X.IP \fBz\fP
  250. XSuspend
  251. X.I wm
  252. by using the Berkeley job control system,
  253. or perhaps by spawning a non-window subshell.
  254. X.IP "\fBh\fP or \fB?\fP"
  255. Help.
  256. Displays a summary of
  257. X.I wm
  258. commands.
  259. X.SH FILES
  260. X.IP \fI.wmrc\fP
  261. X.IP \fI$HOME/.wmrc\fP
  262. used to save the arrangement of your windows from one session to the next.
  263. X.SH BUGS
  264. It'll never beat a BLIT.
  265. X.SH "SEE ALSO"
  266. R.J.K. Jacob,
  267. "User-Level Window Managers for UNIX,"
  268. X.I "Proc. UniForum International Conference on UNIX,"
  269. pp. 123-133 (1984).
  270. X.SH AUTHOR
  271. Robert J.K. Jacob
  272. X.br
  273. Naval Research Laboratory
  274. X.sp
  275. Revised by Matt Lennon and Tom Truscott
  276. X.br
  277. Research Triangle Institute
  278. SHAR_EOF
  279. if test 5635 -ne "`wc -c < 'wm.1'`"
  280. then
  281.     echo shar: error transmitting "'wm.1'" '(should have been 5635 characters)'
  282. fi
  283. fi # end of overwriting check
  284. echo shar: extracting "'USINGWM'" '(17319 characters)'
  285. if test -f 'USINGWM'
  286. then
  287.     echo shar: will not over-write existing file "'USINGWM'"
  288. else
  289. sed 's/^X//' << \SHAR_EOF > 'USINGWM'
  290. X.TL
  291. How I use WM
  292. X.AU
  293. Tom Truscott
  294. X.AI
  295. Research Triangle Institute
  296. P.O. Box 12194
  297. RTP, NC  27709
  298. (919) 541-7005
  299. X.SH
  300. XStarting up wm
  301. X.PP
  302. The last line in my .profile is
  303. X.DS
  304. X.ft PO
  305. exec wm
  306. X.ft P
  307. X.DE
  308. which puts me into the window manager,
  309. so I am always in it.
  310. When I need a real terminal
  311. (e.g. to run `talk')
  312. I can type \fI<wm-esc>\fPz.
  313. XSince I go right into wm
  314. it is important
  315. that TERM be set correctly.
  316. Earlier in my .profile I have
  317. X.DS
  318. X.ft PO
  319. export TERM
  320. case "$TERM" in
  321. sw|su)    TERM=`whatterm`;;
  322. esac
  323. X.ft P
  324. X.DE
  325. XSo that if the TERM variable is su or sw (dataSWitch)
  326. John Menges' whatterm program is invoked to figure things out.
  327. (Whatterm depends on the
  328. response characteristics of a dozen or so terminals.
  329. A more general version, using a `responsecap' database,
  330. is planned.)
  331. Whatterm is doomed to fail on an ADM terminal
  332. (unless it has the HERE-IS option)
  333. and also fails
  334. if the user is already in wm and and logging in to another computer,
  335. because `wm' itself does not respond to any escape sequences.
  336. It probably should, so whatterm will work!
  337. Actually, nested invocations of wm, while amusing,
  338. are probably unnecessarily confusing.
  339. X.SH
  340. Choosing window layout
  341. X.PP
  342. That is largely a matter of individual taste.
  343. My ``#1'' window is full-screen (except for the bottom line),
  344. my #2 window is the top half of the screen and my #3
  345. window is the bottom half (with an unused line between them),
  346. and my #4 window is just like #1.
  347. I am normally (99%) in the #1 window and am generally
  348. unaware of the existence of wm.
  349. But when I want
  350. to escape from the current window I can change to window #4
  351. to get a fresh screen (one wm nuisance is
  352. that it puts me back in my home directory on my home machine).
  353. Or if I want split screens, say for debugging or file comparison,
  354. I can change to window #2 and then alternate between #2 and #3.
  355. I think of having three window layers, the #1 layer,
  356. the #2/#3 layer, and the #4 layer.
  357. (In reality, wm maintains a window display order,
  358. and changing to a window puts that window on `top',
  359. so there is not really a #2/#3 layer.)
  360. On a 66 line display I bet things would be much nicer.
  361. XSome people have a window which covers all but the top line,
  362. so they can put a clock or periodic `uptime' in the top line.
  363. (Note: two windows \fImust\fP have an unused line between them
  364. or else they cannot be used for simultaneous displays.)
  365. Also, some people change the wm prefix character to `^W' or `^P'
  366. so that `vi' is easier to use.
  367. X.PP
  368. The undocumented experimental \fI<wm-esc>\fPf (`fit') command is also handy.
  369. XFor example, suppose I am in my #1 window and type ``make''.
  370. It might take a while, so I would like to switch to another window
  371. and read news.
  372. But I would also like to see the progress of the make.
  373. XSo I switch to a half-screen window and type `\fI<wm-esc>\fPf 1',
  374. which relocates the #1 window so that it is no longer obscured.
  375. Now I can read news and keep up with the ``make'' at the same time.
  376. This can really jumble up the windows,
  377. but in this case I can change back to #1
  378. and do a `\fI<wm-esc>\fPf 1' to make it full-screen again.
  379. X.SH
  380. Window ``Performance'' Considerations
  381. X.PP
  382. There are some important performance details to consider.
  383. XFirst, your terminal needs insert-line/delete-line
  384. or scrolling region support for wm to work well
  385. on anything but full-screen windows.
  386. In particular, my #2/#3 windows are sloowww without such support.
  387. The scrolling region is best because with insert/delete-line
  388. scrolling in the #2 window causes the #3 window to jitter up and down.
  389. By the way, the scrolling region capability is often omitted in
  390. many termcap entries, so you might need to put it in.
  391. Here is the relevant vt100 stuff, which is probably the
  392. only scrolling region support you are likely to find:
  393. X.DS
  394. X.ft PO
  395. X.\" note: the '\e' below is troff's way of saying '\'
  396. :sc=\eE7:rc=\eE8:cs=\eE[%i%d;%dr:sr=5\eEM:
  397. X.ft P
  398. X.DE
  399. XFor now, all of ``cs'', ``sc'', ``rc'', and ``sr'' must be specified
  400. or wm will not use scrolling regions.
  401. X.PP
  402. By all means you should make windows be the full width of the screen.
  403. Without that wm scrolls by redrawing the whole window.
  404. The painful slowness is tolerable for smaller windows,
  405. and also for faster terminal speeds.
  406. My office terminal is at 4800 baud, and wm is okay at that speed,
  407. but even 19200 is probably too slow for a window that is full-screen
  408. except for the right-most column.
  409. X.SH
  410. WM Enhancements
  411. X.PP
  412. The ``Hacking WM'' document mentions several possible enhancements.
  413. XSuggestions for other improvements to wm are welcome.
  414. Code for any new improvements are even more welcome!
  415. X.bp
  416. X.TL
  417. Hacking WM
  418. (Obscure Details for the Hard-Core User)
  419. X.AU
  420. Tom Truscott
  421. X.AI
  422. Research Triangle Institute
  423. P.O. Box 12194
  424. RTP, NC  27709
  425. (919) 541-7005
  426. X.SH
  427. In Praise of Matt Lennon
  428. X.PP
  429. Matt Lennon took an interest in Robert Jacob's Usenet wm distribution,
  430. got it running here, and talked others into trying it out.
  431. XFrankly, the original version was too slow to be usable,
  432. although it was indeed interesting.
  433. (Perhaps most interesting of all was that Jacob had a version
  434. of wm running under UNIX V6!)
  435. Matt reorganized the program internally and put in the first
  436. of a series of scrolling hacks (in WMinsertln and WMdeleteln).
  437. The resulting program shares with the original wm a simplicity of design
  438. that is important in any program, but particularly in a window manager.
  439. I think of the revised wm as the ``A'' version.
  440. I am afraid a ``B'' version will be along all too soon.
  441. X.SH
  442. Problems with Running Programs under WM
  443. X.PP
  444. There are three common problems when running programs under wm.
  445. One problem is that some programs assume
  446. the screen is at least some minimum size, such as 24 lines and 80 columns.
  447. Typical programs betray themselves by scribbling text
  448. intended for ``line 24'' at random places on the screen,
  449. or by dumping core after the ``newwin'' curses routine refuses
  450. to create a window that encompasses that line.
  451. XFixing such programs can be a chore,
  452. but often one can just substitute `COLS' for 80, `LINES-1' for 23,
  453. and so on.
  454. Rogomatic demands 24 lines so I hacked it to overlay all lines >= LINES
  455. onto line LINES-1, which is messy but tolerable.
  456. XFor programs beyond hope, type \fI<wm-esc>\fPz and run the program
  457. on the real terminal.
  458. X.PP
  459. A second problem is with programs that assume a specific terminal type,
  460. such as "vt100".
  461. Wm currently understands only the pseudo-terminal
  462. type "wmvirt", so such programs cannot be run under wm.
  463. It would be nice if wm could emulate an arbitrary
  464. terminal type.
  465. Then one could run wm on an ADM terminal
  466. with one window emulating a vt100 and another emulating a Tektronix 4014.
  467. Of course, wm would need to support viewports into windows.
  468. Viewports are trivial compared to emulating 4014 graphics, however.
  469. X.PP
  470. A third problem is that some programs use getlogin
  471. to determine the user's login name,
  472. but under wm getlogin fails since no one is logged in
  473. on the window's control terminal (pseudo-tty).
  474. The easiest fix is to replace calls to getlogin
  475. with calls to safegetlogin:
  476. X.DS
  477. X.ft PO
  478. /*
  479.  * Returns a user name such that uid(user name) == getuid().
  480.  * If feasible, the session login name is used,
  481.  * but if the real uid has been changed (e.g. via 'su')
  482.  * or if certain file descriptors have been munged
  483.  * then a user name corresponding to the real uid is returned instead.
  484.  * Returns NULL if everything fails.
  485.  * Beware!  Clobbers static data from earlier calls to getpw*.
  486.  */
  487.  
  488. #include <pwd.h>
  489.  
  490. char *
  491. safegetlogin()
  492. {
  493.     register char *p;
  494.     register int uid;
  495.     register struct passwd *pwd;
  496.     static char namebuf[50];
  497.     extern char *getlogin();
  498.  
  499.     uid = getuid();
  500.     p = getlogin();
  501.     /* cannot trust getlogin, so here is a security check */
  502.     if (!p || !(pwd = getpwnam(p)) || uid != pwd->pw_uid)
  503.         p = 0;
  504.     /* if getlogin failed, try the real uid */
  505.     if (!p && (pwd = getpwuid(uid)))
  506.         p = pwd->pw_name;
  507.     if (p) {
  508.         strncpy(namebuf, p, sizeof(namebuf)-1);
  509.         p = namebuf;
  510.     }
  511.     return(p);
  512. }
  513. X.ft P
  514. X.DE
  515. This fixes the `galaxy' and `robots' programs, for example.
  516. We keep this routine in /usr/local/liblocal.a and link programs
  517. that call it with `-llocal'.
  518. Alas, one case that this misses is the command ``who  am  i''.
  519. The trade secret status of ``who'' precludes a clearer explanation.
  520. X.SH
  521. XSupport for Fast Scrolling of any Rectangular Window
  522. X.PP
  523. A (very) few terminals support general ``scrolling rectangles.''
  524. These are wonderful for wm because then
  525. non-full-width windows scroll quickly.
  526. Terminfo already has the ``set_window'' string capability,
  527. described in `tparm' format,
  528. to set up a scrolling rectangle.
  529. There is no such capability in termcap so a new ``sw''
  530. capability was invented, using the same format as terminfo.
  531. XFor example, for the HDS Concept 108 we have:
  532. X.DS
  533. X.ft PO
  534. X.\" note: the '\e' below is troff's way of saying '\'
  535. :sw=\eEv%p1%' '%+%c%p3%' '%+%c%p2%p1%-%'!'%+%c%p4%p3%-%'!'%+%c:\e
  536. X.ft P
  537. X.DE
  538. XFor the HDS 200 we have (sorry, this is untested):
  539. X.DS
  540. X.ft PO
  541. X.\" note: the '\e' below is troff's way of saying '\'
  542. :sw=\eE[%p1%{1}%+%d;%p2%{1}%+%d;%p3%{1}%+%d;%p4%{1}%+%dr:\e
  543. X.ft P
  544. X.DE
  545. You also need ``sr'' (scroll_reverse) for wm to use set_window.
  546. Wm assumes that the set_window command moves the cursor
  547. to the rectangle's home position (upper left),
  548. that cursor motion commands work in the rectangle,
  549. and that the motions are relative to the origin of the rectangle.
  550. If your terminal works differently, and it probably will,
  551. you might have to hack wm.
  552. Look for "SET_WINDOW" which, if defined, causes
  553. code to be generated to support scroll rectangles.
  554. X.SH
  555. LIBCURSES
  556. X.PP
  557. Wm depends heavily on the underlying screen management software (libcurses)
  558. for correctness and efficiency.
  559. A number of changes were found to be needed in libcurses
  560. to provide correctness.
  561. The major efficiency problem has been that of providing fast scrolling.
  562. Libcurses itself does not support insert/delete line or
  563. scrolling regions to provide fast scrolling.
  564. We decided not to put such support into libcurses,
  565. because that was considered too far-reaching,
  566. so insert/delete line and scrolling regions are handled
  567. within special code in wm itself,
  568. and the libcurses windows are accordingly fixed up.
  569. Wm could support scrolling regions more efficiently
  570. (by not switching back and forth between full screen
  571. and window-sized regions on every newline).
  572. It could also handle certain non-full-width windows better.
  573. XFor example to scroll a window that covers all but the rightmost column
  574. it could scroll all lines involved and then redraw the rightmost column.
  575. Perhaps the termlib or other packages do that sort of thing.
  576. Also, for non-full-width windows wm could perhaps scroll two
  577. or more lines at a time, or possibly even wrap around
  578. to the top line rather than scroll.
  579. X.SH
  580. WM and TERMINFO
  581. X.PP
  582. Wm can be compiled with
  583. Pavel Curtis' public domain ``terminfo'' library
  584. in addition to the usual one (``Curses Classic'').
  585. During compilation the TERMINFO preprocessor variable is defined
  586. if compilation with terminfo curses is detected,
  587. so that appropriate code is generated.
  588. The terminfo conventions are nicer than the classic version
  589. so wm uses the terminfo functions and variable names,
  590. and Curses Classic is supported by redefinitions and emulation routines.
  591. X.PP
  592. However, wm really should only be compiled with Curses Classic.
  593. The terminfo version is slower, bigger, buggier, and does not
  594. support arrow keys.
  595. Terminfo also has more fundamental problems.
  596. It does not provide support for the TERMCAP environment variable,
  597. and there is no easy way to construct a terminfo binary file
  598. analogous to the 'wmvirt' TERMCAP string.
  599. As a result wm cannot support any terminfo-compiled applications programs.
  600. When (if) this becomes a problem there will be additional incentive
  601. for wm to be able to emulate an arbitrary terminal
  602. (also see ``problems with running programs under wm'', above).
  603. Then, in conjunction with the 4.3 kernel support for window sizes,
  604. wm can dispense with the TERMCAP variable and emulate whatever
  605. terminal is desired, thus supporting both termcap and terminfo.
  606. (\fI<wm-esc>\fPt will still be needed for tip and cu.)
  607. X.SH
  608. WM response sluggishness
  609. X.PP
  610. An unfortunate current side-effect of wm is that certain
  611. normally responsive terminal operations are now sluggish.
  612. XFor example, if you cat a file and press <Interrupt>
  613. several lines will be printed before the interrupt
  614. takes effect.
  615. Other similar special characters are also handled slowly.
  616. The reason is that wm runs in raw mode, so such characters
  617. are not ``instantly'' handled in the kernel.
  618. Instead they are passed to the currently selected
  619. pseudo-tty, which then interrupts or stops or whatever.
  620. But any characters currently queued by wm for the user's terminal
  621. are still printed!
  622. (The script program has the same behavior,
  623. but it is tolerable for the normal uses of that command.)
  624. There does not seem to be a good way around this problem.
  625. Wm's current approach is to
  626. X.IP a)
  627. Only read a few (currently 64) characters from each pseudo-tty
  628. at a time, to avoid large queues from wm to the real tty.
  629. X.IP b)
  630. Have wm check the size of the output queue using the undocumented
  631. TIOCOUTQ ioctl, and delay reading from the pseudo-ttys
  632. if the output queue is large.
  633. X.IP c)
  634. Have wm reduce the read and queue sizes for a while after the user
  635. types Control-S.
  636. X.LP
  637. The first two hacks keep the response to <Interrupt> at a tolerable level.
  638. They also keep the tty high water mark from
  639. being reached, which would put wm to sleep,
  640. which would make response very sluggish indeed.
  641. The last hack gives somewhat better response to Control-S.
  642. X.PP
  643. This approach to wm sluggishness is quite new,
  644. so more tuning and better approaches to the problem are possibilities.
  645. Also, the parameters have been tuned for a Gould 9050,
  646. which is quite a fast machine, and the resulting
  647. extra cpu involved might be intolerable on a VAX.
  648. An easy `fix' is to comment out the TIOCOUTQ code in wm.c
  649. (you can probably just #undef TIOCOUTQ at the top).
  650. You might want to remove the Control-S hack as well.
  651. X.SH
  652. The `.wmrc' File
  653. X.PP
  654. The first line of .wmrc is the prefix character.
  655. The remaining lines describe the configured windows from bottom
  656. to top.
  657. (The last line describes the window in which the user starts.)
  658. Each line consists of the window name, the number of rows and columns,
  659. and the starting row and column (zero indexed).
  660. If the number of rows (columns) is given as zero then that dimension
  661. ``flexes'' to the height (width) of the screen,
  662. which supposedly is useful when switching among terminals
  663. of different sizes.
  664. X.PP
  665. XSeveral users have asked for the ability to specify an alternate ``shell''
  666. in a window.
  667. That could be done by extending the .wmrc lines to include
  668. a command to be executed in lieu of the shell.
  669. Other users have requested the ability to set the shell prompts
  670. in a window dependent way, among other things.
  671. I do not know how that might be done.
  672. X.SH
  673. The ``SNEAKYTERMCAP'' Method
  674. X.PP
  675. Ordinarily, when a window changes size, wm blasts the window
  676. with a shell command that sets TERM and TERMCAP
  677. to indicate the new window's size.
  678. (This is the same shell command generated by \fI<wm-esc>\fPt.)
  679. This not only produces clutter, it can also confuse non-shell
  680. programs running in that window.
  681. If your version of wm was compiled with SNEAKYTERMCAP defined,
  682. however, a different method is used.
  683. The TERMCAP variable is set to a filename such as /tmp/WM.33445.1
  684. and the file contains the termcap capability string.
  685. Then, when a window changes size the /tmp file is simply rewritten.
  686. But there is a security problem with this method
  687. (or with any command that uses /tmp)
  688. and /tmp gets cluttered up with lots of ``WM'' files.
  689. It would be better if the files were kept in a subdirectory
  690. of each user's home directory, and if wm itself cleaned
  691. up dead temporary files (e.g. due to a system crash).
  692. X.SH
  693. Browsing About in WM Windows
  694. X.PP
  695. XSome terminals have extra memory so one can look back
  696. at text that scrolls off the screen.
  697. It would be nice if wm provided that too.
  698. One hundred lines of scrolled typescript should be adequate.
  699. A plausible approach would be to type \fI<wm-esc>\fPv
  700. (for `view') to put the window in browse mode.
  701. Then input to that window is interpreted as requests
  702. to move back and forth in the typescript,
  703. like the `vi' scrolling commands.
  704. Any output to the real window is held pending exit from browse mode,
  705. which might be by typing ``:q'', at which time the window
  706. is reset to its state on entry to browse mode.
  707. Of course, while a window is in browse mode one can still
  708. switch between windows, move, create, and kill windows, and so on.
  709. X.PP
  710. All this can be implemented cleanly with about 100 lines of code
  711. scattered here and there (it has been written),
  712. but what about text searching and the ability to write parts
  713. of the typescript into UNIX files?
  714. What about all the other nifty `vi' commands?
  715. Why not just run `vi' (or your favorite viewing program)
  716. in the browse window!?
  717. Well, here is why not.
  718. Vi has to position itself at the end of the typescript
  719. in order to provide a ``seamless interface'' to wm.
  720. Okay, that's easy.
  721. We need an ``ignore first clear'' kludge so that when
  722. vi initially redraws the screen
  723. the window is not really redrawn.
  724. Uh, well, wm already has kludges.
  725. We need to suppress the vi status line (``seamless interface'' remember),
  726. say by displaying it instead in wm's status area.
  727. Er, uhm.  Yuck!
  728. It could be done, but it sure would be ugly.
  729. Alas, wm does not yet support browse mode.
  730. SHAR_EOF
  731. if test 17319 -ne "`wc -c < 'USINGWM'`"
  732. then
  733.     echo shar: error transmitting "'USINGWM'" '(should have been 17319 characters)'
  734. fi
  735. fi # end of overwriting check
  736. echo shar: extracting "'Paper.jacob'" '(22963 characters)'
  737. if test -f 'Paper.jacob'
  738. then
  739.     echo shar: will not over-write existing file "'Paper.jacob'"
  740. else
  741. sed 's/^X//' << \SHAR_EOF > 'Paper.jacob'
  742. X.rm CH
  743. X.ds CF "\(hy \\n(PN \(hy
  744. X.\"
  745. X.ds >. .
  746. X.rm <.
  747. X.ds >, ,
  748. X.rm <,
  749. X.ds [. " [
  750. X.ds .] ]
  751. X.\"
  752. X.TL
  753. User-Level Window Managers for UNIX
  754. X.AU
  755. Robert J.K. Jacob
  756. X.AI
  757. Naval Research Laboratory
  758. Washington, D.C. 20375
  759. X.AB
  760. X.I Wm
  761. manages a collection of windows on a display terminal.
  762. Each window has its own shell or other interactive program,
  763. running in parallel with those in the other windows.
  764. This permits a user to conduct several interactions with the system in
  765. parallel, each in its own window.
  766. The user can move from one window to another, re-position a window, or
  767. create or delete a window at any time
  768. without losing his or her place in any of the windows.
  769. Windows can overlap or completely obscure one another;
  770. obscured windows can be "lifted" up
  771. and placed on top of the other windows.
  772. X.PP
  773. This paper describes how such a window manager for UNIX\(dg
  774. X.FS
  775. X.PP
  776. \(dgUNIX is a trademark of Bell Laboratories.
  777. X.FE
  778. is implemented as a set of user processes,
  779. without modifications to the UNIX kernel.
  780. It shows how the simple, but well-chosen
  781. facilities provided by the original
  782. (Version 6) UNIX kernel are sufficient to support
  783. X.I wm .
  784. In addition, subsequent versions of
  785. X.I wm
  786. exploit features of the kernel introduced into newer versions of
  787. UNIX to provide faster and more sophisticated window operations,
  788. still implemented entirely at the user level.
  789. X.AE
  790. X.SH
  791. Introduction
  792. X.PP
  793. This paper describes the design of a display window manager for
  794. UNIX implemented entirely as a set of user processes, without modifications to
  795. the UNIX kernel.
  796. It shows how the simple facilities provided by the original
  797. (Version 6) UNIX kernel are sufficient to support such a window
  798. manager.
  799. In addition, more recent versions of the window manager exploit
  800. features of the kernel introduced into newer versions of UNIX to
  801. provide faster and more sophisticated operations in windows,
  802. still implemented entirely outside the kernel.
  803. X.PP
  804. This window manager,
  805. X.I wm ,
  806. provides a UNIX
  807. user the ability to conduct several interactions in parallel, each in
  808. a different window on a text display terminal.
  809. The windows may be created, moved, and temporarily or permanently erased
  810. at any time.
  811. They may also overlap or completely obscure one another, and such hidden or
  812. partially hidden windows may be "lifted" and placed on top of the
  813. other windows as desired.
  814. XFigure 1 shows a snapshot of a
  815. X.I wm
  816. session in progress.
  817. X.SH
  818. User Interface
  819. X.PP
  820. The notion of organizing computer data spatially was propounded
  821. and exploited by Nicholas Negroponte in the Spatial Data Management System\*(<.\*([.2,\|3\*(.]\*(>.
  822. In
  823. X.I wm ,
  824. however, spatial cues are used only to specify a context for a dialogue.
  825. Once a window is selected, further interactions within that window
  826. make use of the
  827. power and abstraction of more conventional user interface techniques.
  828. Teitelman\*([.8\*(.]
  829. made good use of display screen windows for
  830. a collection of parallel interactions with an INTERLISP system.
  831. More recently, several personal computers and workstations have adopted this
  832. window-oriented style of dialogue as their principal mode of interaction.
  833. Other systems similar to the present one have also been provided
  834. under UNIX\*(<.\*([.4,\|7,\|9\*(.]\*(>.
  835. X.PP
  836. Traditional user interfaces for computers
  837. that handle parallel processes
  838. place all inputs and outputs in one chronological
  839. stream, identifying the process associated with each, but interleaving
  840. the data.
  841. The Berkeley job control facilities for UNIX
  842. provide a first attempt at improving this situation\*(<.\*([.5\*(.]\*(>.
  843. X.PP
  844. By contrast, a window-based user interface
  845. enables a user to manage a collection of dialogues by
  846. associating a spatial location with each dialogue, in much the same
  847. way one organizes a desk.
  848. On a desk, all input papers on all topics
  849. are not (one hopes) placed on a single
  850. pile in chronological order, but rather they are divided into piles by topic.
  851. When input for a particular topic is received, the corresponding pile
  852. is located, lifted, and placed on top of other papers, and the necessary
  853. work is done on that pile.
  854. Each topic may thus be associated with
  855. and remembered in terms of a location on the desk.
  856. Recent empirical evidence showed that such a window-oriented
  857. user interface induced better user performance than a more
  858. traditional scrolled message interface in a particular
  859. situation involving several parallel interactions\*(<.\*([.6\*(.]\*(>.
  860. X.PP
  861. X.I Wm
  862. conducts several concurrent dialogues with a UNIX user.
  863. Each takes the form of a UNIX shell, to which
  864. UNIX commands can be given and from which other interactive
  865. programs can be initiated.
  866. Each dialogue is conducted in a separate area of the screen or
  867. X.I window
  868. designated by the user.
  869. At any moment, one of the windows is considered the current input window,
  870. and all keyboard inputs (except for
  871. X.I wm
  872. commands themselves) are sent to the shell
  873. or program associated with that window.
  874. At any time (including in the middle of typing a command in a window),
  875. the designation of the current window may be changed
  876. and a different dialogue begun or resumed.
  877. Outputs resulting from these dialogues will appear in their appropriate
  878. windows as they are generated, regardless of which window is the
  879. current input window.
  880. Output destined for a portion of a window that is obscured by another
  881. window will appear whenever that portion of the window is uncovered.
  882. Windows can be "piled" on one another in any sequence.
  883. X.PP
  884. X.I Wm
  885. was originally designed for use in an intelligent terminal
  886. that could communicate with several computers simultaneously.
  887. Each dialogue with a different computer was associated with a window.
  888. The method is equally applicable to a collection of dialogues,
  889. all with the same computer but on different topics.
  890. XStill, any or all of the present windows can run programs to conduct
  891. interactive dialogues with other computers
  892. (such as
  893. X.I telnet ).
  894. X.SH
  895. Design for "Vanilla" UNIX
  896. X.PP
  897. To implement a system of this sort,
  898. it is necessary for one user process to be able to
  899. manage a collection of other user processes and to mediate all of
  900. their inputs and outputs.
  901. XFor the inputs, it must act as a switch, directing input from the keyboard to
  902. different programs in response to user commands.
  903. XFor the program outputs,
  904. it must place the output of each program in its correct
  905. position on the screen.
  906. X.PP
  907. If adequate primitives for creating and manipulating processes
  908. and for catching their inputs and outputs are provided by the
  909. operating system, a window manager can be built entirely as a
  910. user program.
  911. The original design of UNIX, with its
  912. X.I pipe
  913. and
  914. X.I fork
  915. mechanisms provides a user the right primitives to design such a
  916. system in an elegant fashion without kernel modifications.
  917. X.PP
  918. X.I Wm
  919. initiates and manages its own collection of UNIX processes, including
  920. those run in response to entered commands.
  921. Any conventional UNIX program can be used from
  922. X.I wm ,
  923. provided it does not make significant
  924. assumptions about the nature of its input
  925. and output devices\-that is, it should treat input and output from a
  926. pipe as equivalent to input and output from a terminal or other source.
  927. X.PP
  928. X.I Wm
  929. runs as
  930. X.I 2n+2
  931. parallel UNIX processes of four different types
  932. (where
  933. X.I n
  934. is the number of windows in use).
  935. The division into processes is dictated by the fact that the original UNIX
  936. X.I read
  937. call on an empty pipe or input device causes a process to
  938. block until input becomes available.
  939. Hence there is a separate process for each pipe or device that must be
  940. read asynchronously.
  941. Each such process contains a loop that reads from its
  942. particular pipe or device,
  943. processes the input, and then waits for more.
  944. XFigure 2 shows the processes and pipes that comprise
  945. X.I wm .
  946. X.PP
  947. The
  948. X.B main
  949. process reads from and waits for input from the keyboard.
  950. Input consisting of text is sent to the shell process
  951. associated with the current window and also to the
  952. X.B scrn
  953. process, described below, for echoing.
  954. Input consisting of
  955. X.I wm
  956. commands is interpreted by
  957. X.B main ,
  958. translated into one or more primitive commands plus arguments, and sent to
  959. X.B scrn
  960. for execution.
  961. XSimple changes in the input command language are thus localized in
  962. X.B main .
  963. To change the name, input syntax, or prompt for a command, only the code in
  964. X.B main
  965. need be modified.
  966. XSince input commands are reduced to a somewhat more general set of
  967. primitive commands, some simple new commands may be implemented entirely in
  968. X.B main
  969. as aliases for specific uses or combinations
  970. of the existing primitive commands.
  971. X.PP
  972. The
  973. X.B scrn
  974. process handles all outputs to the screen.
  975. All processes that want to affect the screen must thus place requests
  976. to do so on a common pipe.
  977. X.B Scrn
  978. reads these instructions from the pipe and makes appropriate modifications to
  979. the screen.
  980. X.I Wm
  981. commands that affect the screen layout, such as moving a window, are placed
  982. on this pipe by
  983. X.B main
  984. and handled by
  985. X.B scrn .
  986. Output text characters from the individual shell processes
  987. that belong in a window
  988. are also placed on this pipe along
  989. with a window identifier and a bit
  990. indicating whether the character should be displayed immediately or
  991. just remembered for the next time the display is refreshed.
  992. X.B Scrn
  993. then compares the desired configuration of the screen to a buffer
  994. containing the actual configuration
  995. and transmits the necessary updates.\(dg\ 
  996. X.FS
  997. X.PP
  998. \(dgThe update algorithm
  999. is less sophisticated than the optimization performed in the
  1000. X.I curses
  1001. package\*(<,\*([.1\*(.]\*(>,
  1002. but
  1003. X.I curses
  1004. was not available in Version 6 UNIX.
  1005. This update algorithm
  1006. is also somewhat easier to adapt to unusual terminals, as seen below.
  1007. X.FE
  1008. X.PP
  1009. There is a
  1010. X.B shell
  1011. process associated with each window.
  1012. This is simply the standard UNIX
  1013. X.I sh
  1014. (or any other designated program).
  1015. These
  1016. X.B shell
  1017. processes have no direct access to the terminal, but run as captives of
  1018. X.I wm ,
  1019. connected by pipes, so that their inputs and outputs can be mediated.
  1020. The input to each of these processes is a pipe from
  1021. X.B main ,
  1022. since
  1023. X.B main
  1024. knows which window is the current input window and can place the typed
  1025. input text on the pipe to the corresponding
  1026. X.B shell
  1027. process.
  1028. All outputs of the
  1029. X.B shell
  1030. processes must be sent to
  1031. X.B scrn
  1032. to be displayed, but they must first be tagged with the name of the
  1033. window in which they belong.
  1034. X.PP
  1035. To do this, each window has a
  1036. X.B shmon
  1037. process that monitors the output of the corresponding
  1038. X.B shell
  1039. process.
  1040. The output of each
  1041. X.B shell
  1042. process is a pipe to a corresponding
  1043. X.B shmon
  1044. process.
  1045. Each time output appears on that pipe,
  1046. X.B shmon
  1047. reads it, packages it with a header identifying its window,
  1048. and then places it on the common request pipe to
  1049. X.B scrn .
  1050. X.PP
  1051. X.I Wm
  1052. comprises about 1000 lines of C code\-about 500 each for the
  1053. X.B main
  1054. and
  1055. X.B scrn
  1056. processes and less than 50 for the
  1057. X.B shmon
  1058. process.
  1059. X.SH
  1060. Remarks and Problems with "Vanilla" UNIX
  1061. X.PP
  1062. Each window in
  1063. X.I wm
  1064. emulates an individual glass teletype.
  1065. Inputs appear in the bottom and scroll off the top of a window.
  1066. XSince the standard input and output for all programs run by
  1067. X.I wm
  1068. are really pipes,
  1069. all programs run under
  1070. X.I wm
  1071. should treat their inputs and outputs
  1072. simply as streams of characters, without distinctions between
  1073. terminals and pipes.
  1074. The fact that UNIX and most of its original programs permit a pipe to be
  1075. substituted for a terminal input or output stream is an elegant
  1076. aspect of UNIX that is crucial to
  1077. X.I wm .
  1078. This obtains for most UNIX programs;
  1079. they perform individual "building-block" functions and are thus intended
  1080. to be equally usable individually from the terminal
  1081. or as filters connected to other programs to perform more complex tasks.
  1082. Programs that try to determine whether they
  1083. have access to a real terminal may behave differently or even refuse to run with
  1084. X.I wm .
  1085. XFor example,
  1086. X.I stty
  1087. is meaningless when applied to a pipe rather than a terminal,
  1088. X.I vi
  1089. will refuse to run from a pipe,
  1090. and
  1091. X.I csh
  1092. will not allow job control if it cannot access the terminal.
  1093. (However, note that
  1094. X.I wm
  1095. is really an alternate approach to controlling concurrent jobs.)\ 
  1096. X.PP
  1097. A very rudimentary facility for supporting a
  1098. whole-screen-oriented program is provided.
  1099. It creates a special temporary window,
  1100. creates a
  1101. X.I termcap
  1102. description of a "terminal" that occupies only the corresponding
  1103. area of the actual
  1104. screen, and then provides that description and direct access to the terminal
  1105. to the screen-oriented program until the latter exits.
  1106. X.PP
  1107. XSince
  1108. X.I wm
  1109. operates with the terminal in raw mode,
  1110. it must provide for itself the input line editing functions normally
  1111. provided by the teletype driver.
  1112. X.PP
  1113. Because of the architecture of
  1114. X.I wm ,
  1115. there are no pipes that
  1116. connect one window to another, hence there is no explicit facility for
  1117. communication between windows.
  1118. It can be achieved, however, through the file system.
  1119. A program in one window
  1120. can append to a file while one in another window continuously tries to read
  1121. from the end of that file.
  1122. X.SH
  1123. Terminal Dependencies
  1124. X.PP
  1125. While the newer version of
  1126. X.I wm
  1127. uses
  1128. X.I curses
  1129. to perform all terminal-dependent operations in a
  1130. terminal-independent fashion, terminal dependencies can be
  1131. isolated fairly easily even without
  1132. X.I curses .
  1133. All terminal-dependent code in the original
  1134. X.I wm
  1135. is restricted to a collection of five simple procedures.
  1136. They were originally written separately for each type of terminal,
  1137. but have also been written in terms of the terminal-independent interface,
  1138. X.I termcap ,
  1139. for systems that have it.
  1140. X.PP
  1141. The five procedures perform the following tasks:
  1142. X.RS
  1143. X.IP \fBttyinit\fP 15
  1144. Performs any necessary initialization for the terminal.
  1145. X.IP \fBttyclose\fP 15
  1146. Performs any necessary closing for the terminal before
  1147. X.I wm
  1148. exits or suspends.
  1149. X.IP \fBttymov\fP 15
  1150. Moves the terminal cursor to a given row and column.
  1151. X.IP \fBclearscreen\fP 15
  1152. Clears the terminal screen.
  1153. X.IP \fBclearline\fP 15
  1154. Clears from the cursor to end of the current line
  1155. (not mandatory).
  1156. X.RE
  1157. X.LP
  1158. XFor each of several common terminals, the definitions of these
  1159. procedures comprise about 15 lines of code altogether.
  1160. X.PP
  1161. This approach isolates terminal dependencies sufficiently that
  1162. X.I wm
  1163. can also be adapted for use on graphic displays
  1164. by replacing the above procedures and making other minor changes.
  1165. XSuch a version of
  1166. X.I wm
  1167. has been written to produce output suitable
  1168. for the standard UNIX plot filters (plus some added commands for
  1169. raster graphic displays) and used with a Genisco frame buffer.
  1170. Windows may be in various colors and may use different fonts for their text.
  1171. X.SH
  1172. Design for Version 4.2 UNIX
  1173. X.PP
  1174. Berkeley Version 4.2 VAX UNIX provides new features that make it
  1175. possible to improve
  1176. X.I wm
  1177. significantly.
  1178. By using pseudo-terminals instead of pipes for interprocess
  1179. communication, several of the problems discussed above disappear.
  1180. In addition, the synchronous input/output multiplexing feature of
  1181. the new UNIX makes the former division of
  1182. X.I wm
  1183. into processes as dictated by the blocking read unnecessary.
  1184. A revised version of
  1185. X.I wm ,
  1186. then, solves many of the earlier problems and runs in a single
  1187. process (plus the user's shells).
  1188. It is, however, less interesting and certainly less portable than
  1189. the initial version.
  1190. Again, the facilities are provided entirely in user-level processes,
  1191. without the need for kernel modifications.
  1192. X.PP
  1193. This version of
  1194. X.I wm
  1195. reads from the keyboard and also from the pseudo-terminals associated
  1196. with each window, in a round-robin, using the multiplexed read call
  1197. X.I (select) .
  1198. Keyboard input consisting of text is sent to the pseudo-terminal
  1199. associated with the current window.
  1200. The pseudo-terminal driver itself handles
  1201. echoing (when enabled) and intraline editing,
  1202. obviating the need for
  1203. X.I wm
  1204. to duplicate these functions.
  1205. Keyboard input consisting of
  1206. X.I wm
  1207. commands is processed directly;
  1208. text input is sent to the appropriate pseudo-terminal.
  1209. Output from the pseudo-terminals is read by
  1210. X.I wm ,
  1211. interpreted in terms of
  1212. the cursor control commands of a simple virtual terminal defined by
  1213. X.I wm ,
  1214. and then added to the appropriate screen window for processing by the
  1215. X.I curses
  1216. package\*(<.\*([.1\*(.]\*(>.
  1217. X.PP
  1218. This version of
  1219. X.I wm
  1220. comprises about 1000 lines of C code, all in a single process.
  1221. XFigure 3 shows the architecture of the program.
  1222. X.SH
  1223. Remarks and Problems with Version 4.2 UNIX
  1224. X.PP
  1225. XSince each window is implemented with a pseudo-terminal, the fact
  1226. that a program is running in a window rather than on a real
  1227. terminal is transparent to most programs.
  1228. XSpecifically,
  1229. most screen editors and games may be used, and
  1230. X.I stty
  1231. may be called to change characteristics such as echoing or line editing
  1232. individually for each window.
  1233. XFor example, note that one of the windows in Figure 1 is running
  1234. X.I vi ,
  1235. which has adjusted itself to the window size.
  1236. XSome programs, however, assume that their output devices are
  1237. of some minimum size;
  1238. they will not run well in very small windows.
  1239. Also, programs that attempt to manipulate the controlling
  1240. terminals of process groups will not work properly under
  1241. X.I wm .
  1242. XFor this reason,
  1243. X.I csh
  1244. cannot currently be run in the individual windows instead of
  1245. X.I sh .
  1246. X.PP
  1247. It is generally
  1248. not possible to move a window while an interactive
  1249. program (other than a shell) is running in it.
  1250. XFirst, this is necessary because, whenever a window is moved,
  1251. X.I wm
  1252. sends a shell command to change the
  1253. X.I TERMCAP
  1254. variable for the shell in that window, to describe its new size.
  1255. A more fundamental reason is that the
  1256. X.I curses
  1257. library routines (sensibly)
  1258. do not expect the terminal description to change while
  1259. a program is running, and so make no provision for checking for or
  1260. adapting to such changes.
  1261. X.PP
  1262. XSince pseudo-terminals are a system-wide resource and are usually fixed in
  1263. number, the total number of
  1264. windows that can be in use by all users at any one time
  1265. is limited to the number of pseudo-terminals made available to
  1266. X.I wm .
  1267. X.PP
  1268. A facility for communicating between windows is now easy to provide.
  1269. XSince each window uses a pseudo-terminal, any data sent to its
  1270. slave pseudo-terminal
  1271. will appear in the window;
  1272. and pseudo-terminals are in the name space of the UNIX file
  1273. system and thus available to other processes.
  1274. To simplify use of this feature, when a window is created and a
  1275. pseudo-terminal obtained for it,
  1276. a link to the name of its slave pseudo-terminal is created
  1277. in the user's current directory.
  1278. Any program inside or outside
  1279. X.I wm
  1280. can then write to or read from that file name without prearrangement.
  1281. X.SH
  1282. Program Versions
  1283. X.PP
  1284. These programs are written in C for use with UNIX.
  1285. There are three principal versions:
  1286. X.B wm.v6 ,
  1287. X.B wm.v7 ,
  1288. and
  1289. X.B wm.v42 .
  1290. The first, as described above,
  1291. runs under unmodified Version 6 UNIX on a PDP-11.
  1292. The code for this version was frozen and abandoned several years
  1293. ago, but it is still available.
  1294. X.B Wm.v7
  1295. runs under Version 7 UNIX,
  1296. and the same code also runs on Berkeley 2.8
  1297. and also on a VAX on Berkeley 4.1 and 4.2.
  1298. No changes in the source code are required between the PDP-11
  1299. and VAX, except that constants for the maximum number and size of windows
  1300. are limited by the available memory on a PDP-11.
  1301. This version
  1302. is similar in design to
  1303. X.B wm.v6 ,
  1304. which was described above, but has a number of improvements.
  1305. The newest version,
  1306. X.B wm.v42 ,
  1307. runs only under Berkeley 4.2 on a VAX,
  1308. as described in this paper.
  1309. It uses the
  1310. X.I select
  1311. synchronous input/output multiplexing call,
  1312. which is unique to 4.2, and also other features
  1313. that are found in some, but not all, versions of UNIX, such as
  1314. pseudo-terminals and
  1315. X.I curses .
  1316. At this writing, this version is not yet thoroughly tested on 4.2.
  1317. An intermediate version for use with Versions 2.8 or 4.1
  1318. can also be constructed by adapting some of the features of
  1319. X.B wm.v42
  1320. to
  1321. X.B wm.v7 .
  1322. XFor example, the use of
  1323. X.I curses
  1324. can certainly be adapted to 2.8;
  1325. pseudo-terminals are available on some versions of 4.1;
  1326. and some versions of 4.1 can also simulate a non-blocking read
  1327. on a pseudo-terminal or a short time-out.
  1328. X.SH
  1329. Availability
  1330. X.PP
  1331. Three versions of
  1332. X.I wm
  1333. are available to interested researchers.
  1334. X.RS
  1335. X.IP "\fBwm.v6\fP" 10
  1336. XFor Version 6 UNIX.
  1337. X.IP "\fBwm.v7\fP" 10
  1338. XFor Version 7 UNIX, also runs on Berkeley 2.8, 4.1, and 4.2.
  1339. X.IP "\fBwm.v42\fP" 10
  1340. XFor Berkeley 4.2 UNIX only (but has some features than can be retrofitted to
  1341. X.B wm.v7 ).
  1342. X.RE
  1343. X.LP
  1344. The code can be obtained over the Arpanet by sending a request to
  1345. X.\" the two (hy is to prevent the hyphenation algorithm from splitting nrl-css
  1346. jacob@nrl\(hycss.
  1347. The author can also be reached via uucp
  1348. at ...!decvax!linus!nrl\(hycss!jacob.
  1349. X.SH
  1350. Conclusions
  1351. X.PP
  1352. It is demonstrably feasible to provide a useful and efficient
  1353. display window management facility in UNIX at the user level,
  1354. without support from kernel modifications.
  1355. XSuch a facility can even be provided for the original Version 6 UNIX,
  1356. although some improvements are obtainable by exploiting features
  1357. provided by more recent versions of UNIX.
  1358. X.SH
  1359. Acknowledgments
  1360. X.PP
  1361. I would like to thank
  1362. Mark Cornwell, Rudy Krutar, Alan Parker, and Mark Weiser
  1363. for helpful discussions of this work.
  1364. X.]<
  1365. X.\"Arnold.K.-1980-1
  1366. X.ds [F 1
  1367. X.]-
  1368. X.ds [A K. Arnold
  1369. X.ds [T Screen Updating and Cursor Movement Optimization
  1370. X.ds [R University of California, Berkeley
  1371. X.ds [D 1980
  1372. X.nr [T 0
  1373. X.nr [A 0
  1374. X.nr [O 0
  1375. X.][ 4 tech-report
  1376. X.\"Bolt.R.-1979-2
  1377. X.ds [F 2
  1378. X.]-
  1379. X.ds [A R. Bolt
  1380. X.ds [T Spatial Data Management
  1381. X.ds [I Architecture Machine Group, Massachusetts Institute of Technology
  1382. X.ds [R Technical Report
  1383. X.ds [D 1979
  1384. X.nr [T 0
  1385. X.nr [A 0
  1386. X.nr [O 0
  1387. X.][ 4 tech-report
  1388. X.\"Herot.C.F.-1980-3
  1389. X.ds [F 3
  1390. X.]-
  1391. X.ds [A C.F. Herot
  1392. X.as [A ", R. Carling
  1393. X.as [A ", M. Friedell
  1394. X.as [A ", and D. Kramlich
  1395. X.ds [T A Prototype Spatial Data Management System
  1396. X.ds [J Computer Graphics
  1397. X.ds [V 14
  1398. X.ds [N 3
  1399. X.ds [P 63-70
  1400. X.nr [P 1
  1401. X.ds [D 1980
  1402. X.nr [T 0
  1403. X.nr [A 0
  1404. X.nr [O 0
  1405. X.][ 1 journal-article
  1406. X.\"Horton.M.-1982-4
  1407. X.ds [F 4
  1408. X.]-
  1409. X.ds [A M. Horton
  1410. X.ds [I personal communication
  1411. X.ds [D September 8, 1982
  1412. X.nr [T 0
  1413. X.nr [A 0
  1414. X.nr [O 0
  1415. X.][ 2 book
  1416. X.\"Joy.W.-1980-5
  1417. X.ds [F 5
  1418. X.]-
  1419. X.ds [A W. Joy
  1420. X.ds [T An Introduction to the C Shell
  1421. X.ds [R University of California, Berkeley
  1422. X.ds [D November 1980
  1423. X.nr [T 0
  1424. X.nr [A 0
  1425. X.nr [O 0
  1426. X.][ 4 tech-report
  1427. X.\"Murrel.S.-1983-6
  1428. X.ds [F 6
  1429. X.]-
  1430. X.ds [A S. Murrel
  1431. X.ds [T Computer Communication System Design Affects Group Decision Making
  1432. X.ds [J Proc. Human Factors in Computer Systems Conference
  1433. X.ds [D 1983
  1434. X.ds [P 63-67
  1435. X.nr [P 1
  1436. X.nr [T 0
  1437. X.nr [A 0
  1438. X.nr [O 0
  1439. X.][ 1 journal-article
  1440. X.\"Pike.R.-1983-7
  1441. X.ds [F 7
  1442. X.]-
  1443. X.ds [A R. Pike
  1444. X.ds [T Graphics in Overlapping Bitmap Layers
  1445. X.ds [J ACM Transactions on Graphics
  1446. X.ds [V 2
  1447. X.ds [N 2
  1448. X.ds [D 1983
  1449. X.nr [T 0
  1450. X.nr [A 0
  1451. X.nr [O 0
  1452. X.][ 1 journal-article
  1453. X.\"Teitelman.W.-1979-8
  1454. X.ds [F 8
  1455. X.]-
  1456. X.ds [A W. Teitelman
  1457. X.ds [T A Display Oriented Programmer's Assistant
  1458. X.ds [J International Journal of Man-Machine Studies
  1459. X.ds [V 11
  1460. X.ds [P 157-187
  1461. X.nr [P 1
  1462. X.ds [D 1979
  1463. X.nr [T 0
  1464. X.nr [A 0
  1465. X.nr [O 0
  1466. X.][ 1 journal-article
  1467. X.\"Weiser.M.-1983-9
  1468. X.ds [F 9
  1469. X.]-
  1470. X.ds [A M. Weiser
  1471. X.as [A ", C. Torek
  1472. X.as [A ", R. Trigg
  1473. X.as [A ", and R. Wood
  1474. X.ds [T The Maryland Window System
  1475. X.ds [R Technical Report 1271
  1476. X.ds [I Computer Science Department, University of Maryland
  1477. X.ds [D 1983
  1478. X.nr [T 0
  1479. X.nr [A 0
  1480. X.nr [O 0
  1481. X.][ 4 tech-report
  1482. X.]>
  1483. SHAR_EOF
  1484. if test 22963 -ne "`wc -c < 'Paper.jacob'`"
  1485. then
  1486.     echo shar: error transmitting "'Paper.jacob'" '(should have been 22963 characters)'
  1487. fi
  1488. fi # end of overwriting check
  1489. #    End of shell archive
  1490. exit 0
  1491.